1. Technical Field
The present invention relates in general to the field of data processing, and, in particular, to software. Still more particularly, the present invention relates to managing configuration files used by software.
2. Description of the Related Art
While components of computer software can be categorized in many ways, a useful concept, when describing the present invention, is to consider software (including both operating systems as well as application programs) as being composed of instructions and configuration files. As the name implies, instructions are lines of code that “tell” (instruct) a computer how to manipulate data. Examples of such instructions are “add,” “subtract,” “compare,” etc. By utilizing many such instructions in a logical manner, a computer can perform complex operations, including database management, word processing, graphic design, telecommunication, etc.
While instructions tell a computer how to function, a configuration file tells the instructions what parameters to use. Examples of such parameters include file names used for various software components, page lengths, fonts used by the software, (if the software is an application) what operating system is to be used, etc. There are literally hundreds of parameters that are described and controlled by the entries in the configuration file.
Different operating systems name and utilize their configuration files differently. For example, Unix® user applications often create a configuration file in a home directory of the user upon startup. Unix® server processes often use configuration files in an installation directory, a root directory, or a location defined by a system administrator. Furthermore, some Unix® configuration files run a set of commands upon startup, such as commands to change directories, run certain programs, create or delete certain files, etc., in order to customize the Unix® session.
Microsoft® Windows® operating systems typically use a Windows® registry to store configuration information. The Windows® registry is a database that contains information and settings for hardware, software, users, and preferences of a computer that is running Window®. For example, whenever a user makes changes to “Control Panel” settings, or file associations, system policies, or installed software, the changes are reflected and stored in the registry.
IBM's® OS/2® operating system uses a binary formatted registry file named INI (for “initialization”). Unlike the Window® registry, the OS/2® profile (registry) contains a list of key-value pairs, which describe string, data and Boolean operative properties.
Although technically different in some ways, for the purposes of the presently described invention, the terms “registry,” “registry file,” “configuration file,” and “profile” are used interchangeably to describe a configuration file.
Software packages, which include instructions and registry files, can be upgraded. Therefore, just as the instructions in the software package can be upgraded, so too can the registry files in the software package be upgraded. Registry files for a software package may be upgraded for a current version of software instructions used by that software package; or, more commonly, the registry files may be upgraded when the software instructions are upgraded for a newer version of the software package. For example, FIG. 1A depicts an old version software package 106a being upgraded to a new version software package 106b. During this upgrade, the respective registry files are also upgraded, as shown by an old registry file 108a being upgraded (by migration) to a new registry file 108b. As depicted in FIG. 1A, both the old version software package 106a and the new version software package 106b are stored in a server 102 (e.g., an IBM Websphere® server), which supports at least one client 104. When client 104 requests a copy of a software package, it is typically presented with the latest version of the requested software package (e.g., new version software package 106b). Thus, new registry file 108b is downloaded, as part of the new version software package 106b, to the requesting client 104.
However, there are circumstances in which the client 104 prefers to receive the old version software package 106a. As depicted in FIG. 1B, the server 102 can, responsive to the request from the client 104, download the old version software package 106a to the client 104. The old registry file 108a only contains old registry data, even though new registry file 108b may contain data that could be used by, and useful to, the old version software package 106a that is downloaded to the client 104. However, since the old registry file 108a is a static “snapshot” of data that existed before the upgrade described in FIG. 1A, such changes to the registry file are unavailable to the client 104 that downloads the old version software package 106a. 
Consider now exemplary pseudocode shown in FIG. 1C, which describes the scenario shown in FIGS. 1A-B. Version 5 of software named “WAS.xml” uses a registry data called “keyFileName.” In Version 6 of this software, however, the term “keyFileName” is replaced with the term “provider.” This one time conversion disposes of data that has no significance to the destination version (Version 6), while destructively mutating data such that it is unusable by the source version (Version 5). Thus, the translation is irreversible.